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Abstract 

The  systems  developer  who  needs  PTTI  capability  has  relatively  little  guidance  in  the  form  of 
military  standards,  particularly  for  systems  using  atomic  clocks  or  other  sources  of  very  precise 
time  and  frequency.  This  paper  will  discuss  the  existing  standards,  including  MIL-STD-188-115, 
MIL-F-2991  (EC),  and  DOD-STD-1399.  These  documents  were  written  several  years  ago  and  do 
not  always  reflect  current  practice  or  take  advantage  of  more  recent  technology  improvements.  User 
needs  have  also  changed  over  the  years  and  some  of  those  needs  such  as  more  detailed  time  codes 
are  not  being  met.  We  will  summarize  what’s  available  and  what’s  good  and  bad  about  it. 

The  second  part  of  the  paper  will  make  suggestions  about  what  should  be  done  in  the  future  to 
promote  and  facilitate  good  PTTI  design  practice.  Topics  will  include  clock  performance  parameters, 
environmental  considerations,  time  codes,  signal  isolation  and  time  dissemination , 


EXISTING  STANDARDS  AND  THEIR  ORIGINS 

For  years,  the  annual  Frequency  Control  Symposium  and  the  Precise  Time  and  Time  Interval 
Applications  and  Planning  Meeting  have  tried  to  get  up-to-date  information  on  timing  to  the 
managers  and  designers.  However,  some  of  the  key  people  don’t  know  that  they  exist  and  some 
others  don’t  know  that  they  apply  to  their  programs.  Military  standards  written  to  alert  responsible 
people  to  timing  issues  and  to  impart  some  standardization  into  timing  systems  have  also  had  only 
moderate  success  —  partly  for  the  same  reasons,  but  also  because  of  their  limited  applicability  or 
their  inadequacy  for  some  of  the  newer  systems.  One  way  to  get  the  attention  of  potential  precise 
time  and  frequency  users  is  to  place  references  to  a  DOD-STD  or  a  MIL-STD  in  some  of  the  more 
general  standards,  such  as  those  for  ships,  aircraft,  or  installations,  where  integration  of  the  systems 
should  be  addressed. 

Standardization  is  not  a  new  issue.  The  subject  was  addressed  at  the  PTTI  meeting  in  1980  in  a 
"Government  Planners"  session  and  an  “Industry  reviews  session,  in  1981  in  a  "PTTI  Requirements 
and  Specifications”  forum,  and  in  1982  in  a  panel  discussion  on  “Future  Timing  Requirements”. 
In  1980,  Martin  Bloch  of  FEI  reported  to  the  PTTI  Meeting  that  requiring  small  changes  from 
an  otherwise  fairly  standard  product  was  costing  the  Government  large  amounts  of  money  [1].  In 
1981,  James  Bowser  reported  [2]  that  “...the  planning  process  for  PTTI  support  is  less  than  a 
well  defined,  coordinated  process” . 
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About  10  years  ago,  Dr.  Nicholas  Yannoni  of  RADC  called  a  meeting  of  Air  Force  PTTI  users 
and  found  that  precise  timing  devices  were  far  from  standardized;  some  cesium-beam  standards, 
for  example,  produced  only  special,  non-standard  frequencies.  The  Navy  found  that  each  system 
requiring  PTTI  usually  brought  its  own  standards  aboard,  so  that  there  was  much  duplication, 
but  no  means  of  coordination;  there  was  some  interest  in  the  Navy  for  a  standardized  platform 
distribution  system  [3,  4].  In  general,  timing  systems  (even  those  aboard  the  same  platform)  had 
been  developed  completely  independently.  This  is  still  a  problem,  but  there  has  been  some  effort 
to  resolve  it. 

MIL-STD-188-115  was  developed  as  a  standard  for  timing  and  synchronization  of  tactical  and 
long-haul  communications  systems.  It  included  some  pet  projects  as  well  as  some  useful  standard¬ 
ization.  As  in  many  committees,  there  were  few  specialists  on  the  subject  at  hand,  but  it  was  not 
too  difficult  to  accept  the  precedent  of  DOD-STD-1399-441,  which  had  been  drafted  earlier  by 
NAVELEX  to  help  standardize  Navy  platform  distribution  systems.  1399  had  little  in  the  way  of 
dogma,  but  did  list  some  standard  frequencies  (100  kHz,  1  MHz  and  5  MHz),  precision  time  pulse 
rates  of  1  pulse  per  second  (1  PPS)  and  1  pulse  per  minute  (1PPM),  and  two  time  codes,  each 
having  an  on-time  feature.  One  was  a  50  b/s,  binary-coded-decimal  (BCD),  dc  code  giving  units 
and  tens  of  hours,  minutes,  and  seconds  once  per  second.  (This  time  code  and  the  other  signals 
were  provided  by  the  Navy’s  cesium  beam  specification,  MIL-F-28811(EC).  The  other  was  Time 
Code  2137,  which  gave  the  same  information  once  per  second,  but  used  pulse-width  modulation  at 
a  25  PPS  rate;  the  pulses  could  be  either  dc  or  an  amplitude-modulated  1000  Hz  carrier. 

MIL-STD-188-115  adopted  a  preferred  frequency  of  5  Mhz  (with  5  X  2n  MHz  acceptable)  and  a 
precision  timing  pulse  rate  of  1  PPS.  It  also  required  a  clock  either  to  display  time  of  day  (TOD) 
in  hours,  minutes,  and  seconds  or  to  generate  a  time  code  with  the  same  information.  At  first, 
the  1399  BCD  code  was  considered.  The  goal  for  the  standard  was  a  minimum  interface  to  allow 
collocated  timing  equipment  to  be  shared  or  pooled.  The  purpose  of  the  code  was  simply  to  resolve 
the  ambiguity  of  the  1  PPS,  although  it  could  be  used  as  a  lower-precision,  stand-alone  time 
reference.  However,  there  are  other  aspects  of  precise  timing  that  might  also  be  crammed  into  a 
time  code,  including  the  day  of  the  year  and  a  time  figure  of  merit  (TFOM).  The  BCD  code  was 
therefore  allowed  in  three  versions:  the  6-digit  (24-bit)  TOD  format,  TOD  plus  a  3-digit  (12-bit) 
day  of  year  (DOY),  and  TOD  plus  DOY  plus  a  1-digit  (4-bit)  TFOM. 

The  TFOM  was  a  new  concept,  at  least  to  those  in  the  188-115  working  group.  It  appeared 
that  one  normally  knew  the  capabilities  of  the  reference  systems  that  were  in  use  and  therefore 
knew  the  time  errors  that  could  be  expected.  A  clock  ensemble  might  be  able  to  estimate  its  own 
inaccuracy,  and  a  GPS  receiver  might  give  a  worthwhile  assessment  of  accuracy  based  on  signal- 
to-noise  ratios,  geometry  of  the  satellites  in  use,  and  the  consistency  of  the  time  solution  with  more 
than  the  minimum  number  of  satellites.  However,  except  for  outright  failures  detected  by  built-in 
test  equipment,  a  single  clock  generally  does  not  know  its  own  accuracy.  An  estimate  might  be 
made  from  the  specified  frequency  stability,  the  accuracy  of  the  last  time  and  frequency  updates, 
and  the  elapsed  time  since  the  updates,  but  inaccuracy  can  also  come  from  undetected  failures  or 
environmental  conditions.  The  TFOM,  therefore,  might  be  regarded  as  a  warning,  but  not  as  a 
guarantee,  unless  there  is  a  solid  basis  for  verifying  accuracy.  Nevertheless,  a  TFOM  definition  was 
created  for  188-115.  Using  the  1399-441  definition  of  precise  time  as  10  ms  or  better,  the  largest 
described  error  would  be  “greater  than  10  ms  or  fault”.  The  lower  limit  used  in  the  TFOM  was 
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1  ns,  because  technology  was  pushing  such  precision  (if  not  accuracy),  and  the  188-115  TFOM 
ranked  accuracies  in  decade  steps  from  better  than  1  ns  to  more  than  10  ms. 

When  it  was  found  out  how  the  TFOMs  were  to  be  used,  it  was  apparent  that  the  188-115  TFOM 
was  not  all  that  the  users  wanted.  HAVEQUICK  and  others  were  seeking  ways  to  use  marginally 
capable  clocks  in  what  could  be  called  a  fluid  timing  hierarchy.  The  TFOM  would  be  based  on  a 
sort  of  worst-case  performance  and  the  accuracy  of  the  last  update.  Within  some  ranges  of  timing 
uncertainty,  the  TFOM  would  describe  the  uncertainty  in  increments  as  small  as  ten  percent. 

The  interface  control  document  for  GPS  military  user  equipment  (ICD-GPS-060)  was  being  de¬ 
veloped  at  about  the  same  time  as  MIL-STD-188-115  and  made  use  of  its  timing  interfaces.  It 
provides  for  a  time  display,  the  full  version  of  the  BCD  time  code  (Figure  1),  and  1  PPS  (Figure 
2).  It  can  also  accept  1  PPS  and  the  time  code  for  quick  acquisition  of  the  GPS  satellite  signals. 
Because  of  its  internal  design,  the  user  equipment  (receiver)  could  not  easily  generate  an  accurate 
5  MHz  signal,  so  it  does  not  supply  one,  but  it  did  accept  a  5  MHz  input,  which  it  terminated  with 
a  50  Ohm  resistor.  Besides  the  188-115  interface,  the  GPS  user  equipment  has  two  other  timing 
interfaces:  a  HAVEQUICK  time  code  and  a  MIL-STD-1553  bus  interface. 

HAVEQUICK  is  a  frequency-hopped  communications  system  used  by  aircraft  and  other  platforms. 
The  HAVEQUICK  time  code  is  gaining  in  both  popularity  and  content.  The  most  recent  version 
is  the  third.  The  MK-XV  IFF  was  working  towards  a  similar  code  before  its  development  was 
discontinued,  and  it  might  have  adopted  the  HAVEQUICK  version.  A  working  group  of  NATO  is 
currently  drafting  a  precise  time  and  frequency  standardization  agreement  (STANAG  4430)  and 
appears  to  be  leaning  towards  a  HAVEQUICK— type  code.  The  HAVEQUICK  code  has  a  nominal 
10  pis  resolution,  although  a  shorter  rise  time  could  improve  it. 

The  MIL-STD-1553  bus  is  basically  a  computer  interface.  GPS-ICD-060  showrs  it  used  in  con¬ 
junction  with  the  1  PPS  precision  signal  to  distribute  time. 

STANDARDIZATION  ISSUES 

Standardization  is  more  complex  than  it  first  seems.  Part  of  the  problem  is  the  wide  range  of 
requirements  vs.  resources.  A  common  standard  of  performance,  for  example,  cannot  simultane¬ 
ously  apply  to  a  laboratory  and  a  land-mobile  unit.  Standards  based  on  current  usage  in  the  field 
could  well  stifle  progress.  Part  of  MIL-STD-188-115,  in  fact,  prescribed  performance  standards 
specifically  for  the  long-haul  portion  of  the  Defense  Communications  System.  This  performance 
could  not  be  realized  in  many  applications. 

In  choosing  what  to  standardize,  the  full  effect  on  all  users  must  be  taken  into  account.  Simply 
selecting  a  common  time  scale  can  have  major  implications  for  PTTI:  the  versions  of  UTC  main¬ 
tained  by  different  nations  may  differ  by  tens  of  microseconds.  (The  time  scale  used  by  the  U.S. 
military  is  the  version  maintained  by  the  U.S.  Naval  Observatory  Master  Clock).  Within  the  expert 
PTTI  community,  such  things  can  usually  be  handled  rather  easily,  and  they  might  be  ignored  by 
others  who  need  only  millisecond  accuracy.  For  operational  use  at  greater  accuracies,  they  must  be 
resolved  beforehand,  or  means  must  be  provided  to  the  operators  for  dealing  with  them.  Also,  the 
UTC  leap  seconds  can  and  often  do  lead  to  disorder  within  systems  that  need  precise  time  only  for 
synchronization.  Some  systems  such  as  GPS  and  LORAN  C  do  not  observe  them;  International 
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Atomic  Time  might  also  be  considered,  but  by  going  to  any  different  time  scale,  a  correction  would 
have  to  be  applied  to  the  time  given  by  the  numerous  UTC  time-dissemination  services. 

Perhaps  the  best  that  can  be  done  now  is  to  standardize  an  interface  that  will  not  limit  performance. 
Clock  performance  will,  of  course,  continue  to  be  platform-dependent,  and  each  platform  will 
require  a  clock  that  can  satisfy  its  most  demanding  user  system.  However,  a  standardized  interface 
that  would  support  more  demanding  uses  might  still  be  realized  if  it  does  not  intrude  unnecessarily 
on  system  or  platform  design. 

Assuming  that  the  purposes  of  standardizing  are  to  permit  comparisons  of  clocks  and  to  facilitate 
interoperation  and  time  and  frequency  distribution,  the  elements  specified  in  MIL-STD-188-115  (a 
precision  timing  pulse,  a  time  code  and  a  standard  frequency)  would  seem  appropriate,  although  the 
specifics  of  MIL-STD-188 — 115  might  be  subject  to  debate.  For  example,  instead  of  the  precision 
timing  pulse,  a  precise  timing  mark  might  be  some  feature  of  the  time  code  that  describes  when  the 
mark  occurred.  For  that  matter,  a  standard  frequency  might  also  be  recovered  indirectly  from  the 
time  code  or  the  timing  marks,  but  there  is  normally  a  need  for  clean,  accurate  standard  frequencies 
in  a  precisely  timed  system. 

It  is  a  foregone  conclusion  that  not  all  systems  will  be  able  to  use  the  standardized  signals  and 
formate  per  se.  An  array  of  adapters  or  converters  might  be  fielded  to  serve  systems  that  cannot  use 
the  standardized  interface  directly,  but  the  interface  should  be  chosen  to  serve  the  great  majority 
of  current  and  future  users  without  conversion. 

In  designing  an  interface,  it  must  be  considered  how  signals  will  be  brought  to  and  from  it  and 
possibly  even  what  connectors  or  physical  connections  will  constitute  the  interface.  Because  of  the 
great  amount  of  existing  equipment  and  the  local  nature  of  most  distribution  systems,  the  interface 
should  probably  be  electrical,  even  if  fiber-optic  lines  are  sometimes  used.  Since  the  standard 
frequency  and  precision  timing  signals  are  analog  (as  is  the  time  code  if  its  on-time  feature  is  to 
be  used  as  a  time  reference),  small  amounts  of  interference  or  noise  can  degrade  them.  For  precise 
work,  connectors  should  provide  continuity  of  shielding  used  on  the  signal-bearing  lines.  Multi-pin 
connectors  without  individual  line  shielding  should  generally  be  avoided  in  order  to  reduce  crosstalk 
and  electromagnetic  interference  (EMI).  There  are,  however,  many  uses  of  timing  signals  that  are 
borderline  according  to  the  PTTI  definition  and  for  which  multiple-conductor  cables  might  suffice. 

STANDARD  FREQUENCY  INTERFACES 

Some  performance  attributes  of  interest  at  a  standard  frequency  interface  are  the  sometimes  heav¬ 
ily  overlapping  qualities  of  frequency  stability,  spectral  purity,  single-sideband  phase  noise,  har¬ 
monic  content  (for  sine  waves),  spurious  signal  content,  and  jitter.  Frequency  accuracy  is  a  perfor¬ 
mance  function  of  the  frequency  reference,  and  the  standard  interface  is  intended  only  to  preserve 
accuracy — not  to  establish  it.  It  is  assumed  here  that  the  phase  of  the  standard  frequency  is  of 
no  interest  to  the  user,  but  the  constancy  of  the  phase  relationship  with  respect  to  the  precision 
timing  signal  might  well  be  consequential.  It  is  probably  too  much  to  ask  that  an  absolute  phase 
relationship  between  the  two  signals  be  specified  at  the  interface  since  they  will  most  likely  be  dis¬ 
tributed  on  separate  lines,  and  the  interpretation  of  the  timing  signal  may  also  vary  somewhat  from 
user  to  user.  An  important  relationship  for  many  systems  is  that  the  standard  frequency  and  the 
precision  time  signal  be  derived  from  the  same  clocking  signal;  thus,  equipment  using  the  standard 
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frequency  would  not  have  to  be  reset  occasionally  to  maintain  agreement  with  the  precision  time 
pulse. 

The  nominal  frequency  of  the  signal  deserves  some  consideration.  5  MHz  has  been  used  by  much 
military  and  civilian  equipment  and  is  a  good  compromise  frequency  for  many  purposes,  although 
10  MHz  is  gaining  popularity.  At  5  MHz,  losses  in  common  coaxial  lines  are  low  enough  that  it 
can  be  distributed  more  than  1000  feet  with  less  than  6  dB  loss.  At  higher  frequencies,  losses 
would  increase,  but  at  lower  frequencies,  small  amounts  of  noise  or  interference  would  cause  larger 
fractional  frequency  deviations  or  jitter.  Conceptually,  the  MIL  STD-188  115  preferred  frequency 
of  5  MHz,  with  options  of  5  MHz  X  2n  may  have  some  merit,  although  most  existing  5  MHz 
equipment  would  require  an  active  frequency  divider  (and  perhaps  a  filter)  if  n  >  0. 

A  standard  frequency  signal  might  be  distributed  as  a  sine  wave  or  a  pulse  chain,  such  as  a  square 
wave.  Narrow  band  filtering  can  be  used  to  recover  the  fundamental  frequency  of  a  square  wave. 
However,  a  sine  wave  having  the  same  fundamental  power  as  a  square  wave  would  cause  less  EMI. 
A  low-duty-cycle  pulse  train  which  could  be  generated  with  less  power  expenditure  than  a  square 
wave  would  provide  little  power  at  the  fundamental  frequency,  and  triggering  techniques  would 
likely  be  employed  to  recover  it;  false  triggering  would  be  a  threat  in  an  impulse-noise  environment 
and  could  produce  very  large  instability  in  the  recovered  signal.  The  voltage  and  impedance  of  the 
standard  frequency  signal  might  be  specified,  although  distribution  amplifiers  or  attenuators  can 
be  used  to  adjust  the  voltage  if  the  equipment  can  deliver  a  clean  signal  to  the  interface. 

TIME  CODE  INTERFACES 

While  MIL-STD-188-115  permits  either  a  time  readout  or  a  time  code,  a  time  code  is  more  useful 
if  timing  information  must  be  distributed  around  a  platform  or  installation.  Other  situations  that 
would  be  best  served  by  a  time  code  include  initializing  a  precise  time  reference  of  an  aircraft  or 
land  mobile  platform  whose  power  had  been  turned  off.  In  these  cases,  if  the  mobile  unit  is  then 
to  maintain  time  autonomously,  other  information,  such  as  the  date  and  direction  of  an  impending 
leap  second,  would  be  needed.  For  some  automatic  equipment,  the  day  of  the  year  and  even  the 
year  of  the  century  would  also  be  required.  For  distribution  around  a  platform  or  installation,  a 
TFOM  would  not  ordinarily  be  especially  useful,  except  to  declare  failures  detected  by  built-in  test 
equipment  or  to  warn  a  lower-level  disciplined  clock  of  substandard  service  being  provided  to  it. 
If  the  platform  might  later  use  a  time  reference  such  as  GPS,  it  may  be  more  convenient  for  the 
externally  loaded  time  code  and,  the  one  provided  by  the  GPS  receiver  to  be  in  the  same  format, 
or  at  least  a  compatible  format. 

In  the  past,  much  information  now  being  asked  for  in  the  various  time  codes  was  supplied  manually. 
A  “universal”  time  code  might  be  developed,  but  before  doing  so,  a  wider  search  of  time-code  needs 
and  practices  should  be  made.  Some  thought  might  also  be  given  to  adapting  an  existing  code. 
The  50-bit-per-second  BCD  code  has  insufficient  room  for  expansion.  The  HAVEQUICK  code 
does  not  give  leap-second  information,  although  there  seems  to  be  enough  room  for  considerable 
expansion.  The  IRIG  A,  B,  and  G  codes  give  a  time  of  year  at  least  once  per  second,  but  do  not 
give  the  YOG,  TFOM,  or  leap-second  information.  The  “control”  bits  available  in  them  might  be 
designated  to  supply  the  other  information.  If  the  HAVEQUICK  or  an  IRIG  code  is  selected  as 
the  standard,  any  added  bits  or  the  use  of  existing  control  bits  should  be  standardized;  it  would 


127 


be  prudent  also  to  leave  sufficient  room  for  additional  information  that  might  become  standardized 
later.  Even  so,  it  would  not  be  surprising  if  other  functions  were  tacked  onto  the  code  just  because 
it  is  convenient. 


PRECISION  TIMING  SIGNAL  INTERFACES 

A  precision  timing  signal  might  be  part  of  a  time  code,  or  it  could  be  a  separate  pulse  rate.  One 
pulse  per  second  has  been  widely  used  in  precise  timing;  the  GPS  user  equipment  ICD,  MIL-STD- 
188-115,  and  much  existing  equipment  specify  a  positive  20  us  pulse  with  a  rise  time  of  less  than 
20  ns.  This  is  a  reasonable  specification  for  much  work,  and  it  doesn’t  take  too  much  coaxial  cable 
to  stretch  a  shorter  rise  time  to  20  ns  or  more,  anyway.  Earlier  equipment  used  a  10  V  pulse,  but 
some  devices  now  use  transistor-transistor-logic  (TTL)  output  levels.  (A  TTL  50  Ohm  line  driver 
usually  delivers  about  a  3  V  pulse). 

However,  some  laboratories  and  even  operational  systems  are  now  dealing  with  single-nanosecond 
resolution.  How  different  measuring  instruments  respond  to  a  pulse  rise  of  20  ns  (or  more)  is  then 
pivotal.  Given  the  difficulty  of  maintaining  a  shorter  rise  time,  even  if  one  were  generated,  a  more 
practical  approach  may  be  to  standardize  on  how  a  pulse  is  perceived  by  a  user  or  measurement 
system.  USNO  has  regularly  used  a  specific  voltage  threshold  in  their  portable  clock  measurements. 
(A  1  V  threshold  used  earlier  was  later  changed  to  1.5  V  to  avoid  noise  that  was  present  on  some 
systems).  But  the  difference  in  their  practice  and  how  a  VS  AT  two-way  time  transfer  modem  or 
a  GPS  receiver  used  in  simultaneous  viewing  would  perceive  the  pulse  might  differ  by  a  much  as, 
say,  10  ns. 

If  a  measurement  standard  were  to  be  adopted,  it  might  well  include  some  other  features  that 
would  improve  reproducibility.  In  some  of  the  current  (10  V)  pulse-generation  specifications,  the 
tolerances  of  the  low  and  high  levels  of  the  pulse  are  one  volt.  These  are  simply  undesirable  by¬ 
products  of  pulse  generation,  but  they  limit  flexibility  in  choosing  a  threshold.  If  the  measurement 
system  used  capacitor  coupling  (e.g.,  the  circuit  of  Figure  3),  only  the  dynamic  portion  of  the  pulse 
would  be  of  interest,  and  the  tolerance  of  the  low  level  would  not  be  a  concern.  Furthermore,  if 
the  pulse  rate  is  once  per  second,  an  input  circuit  time  constant  might  be  made  small  enough  to 
reduce  considerably  the  often  experienced  effects  of  ground  loops  at  mains  frequencies  of  50  or  60 
Hz. 

A  standard  input  circuit  would  not  be  needed  by  most  users.  However,  if  one  is  specified,  it  should 
be  able  to  operate  with  both  the  10  V  and  the  TTL-level  1-pulse-per  second  signals.  The  following 
specifications  might  be  appropriate: 
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Input  Impedance: 


Nominal  value:  50  Ohms 
VSWR:  <1.1  from  20  kHz  to  200  MHz 
<1.3  below  20  kHz 
DC  resistance:  50  Ohms  ±10  Ohms 


Trigger  circuit:  Capacitor  Input: 


Time  constant  —  100  ±  20  /is 

Trigger  point:  +1  V  ±  0.1  V  on  dynamic  rise 


The  VSWR  specification  is  necessary  both  to  avoid  reflections  and  to  set  a  standard  impedance  for 
measuring  the  pulse.  A  time  constant  of  100  fi$  is  large  enough  to  work  with  pulses  of  very  large 
rise  time  (although  accuracy  would  suffer)  and  small  enough  to  discriminate  against  60  Hz  signals 
by  almost  30  dB.  A  strict  tolerance  on  the  time  constant  is  not  needed  unless  the  pulse  rise  time 
is  more  than  10  ps. 

The  length  of  the  pulse  is  not  especially  critical  if  the  leading  edge  is  used  as  the  reference  feature. 
Only  low-accuracy  timing  systems  could  use  a  long  pulse  to  advantage;  otherwise,  a  long  pulse  is 
just  a  wraste  of  energy.  A  10  or  20  /ns  pulse  should  be  adequate  for  local  distribution. 

SUMMARY 

A  standard  precise  time  and  time  interval  interface  could  make  it  easier  to  serve  and  coordinate 
precisely  timed  military  systems.  Money  could  be  saved;  in  some  cases,  by  pooling  or  coordinating 
platform  resources,  performance  and  reliability  could  be  improved.  The  degree  of  standardization 
w'ill  undoubtedly  be  a  compromise  because  of  the  amount  of  existing  equipment  and  the  wide  range 
of  requirements  and  the  technologies  available  to  support  them.  Just  standardizing  the  types  of 
signals  at  a  standard  interface  would  be  a  step  forward,  even  if  amplifiers,  hybrid  connectors,  or 
other  crutch  as  are  sometimes  needed. 

Probably  the  most  controversial  element  will  be  the  time  code.  Several  different  time  codes  may 
be  needed  to  serve  different  types  of  users.  Modulated-carrier  time  codes,  for  example,  are  still 
needed  for  instrumentation  recorders  that  cannot  record  DC  signals  and  might  also  be  used  in 
voice-frequency  circuits.  DC  codes  are  easier  to  generate  and  use  in  most  other  local  applications. 
The  MIL-STD-1553  code  could  be  used  to  interface  with  computers,  although  for  precise  work,  a 
precision  timing  pulse  is  also  needed. 

The  content  of  a  code  would  depend  on  where  the  basic  information  would  be  injected  into  the 
timing  hierarchy.  For  example,  will  leap-second,  day  of  year,  or  year  of  century  information  be 
injected  manually?  If  so,  where?  If  TFOMs  are  used,  there  should  be  a  standard  method  of 
determining  them  or  at  least  evaluating  the  confidence  that  should  be  placed  on  them.  Used 
indiscriminately,  TFOMs  can  cause  large  reliability  problems.  For  the  purpose  of  standardization, 
a  coarse  TFOM  such  as  provided  in  MIL-STD-188-115,  or  even  just  a  warning  flag,  might  be 
adequate.  The  coarseness  actually  may  be  advantageous,  because  it  would  tend  to  discourage  its 
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Use  for  selecting  a  reference  based  on  minor  and  meaningless  TFOM  differences.  Space  might  be 
reserved  in  the  code  for  user-defined  TFOMs  or  other  user-specific  information;  if  it  is,  the  type  of 
user  should  also  be  identified  so  that  other  user  types  would  not  be  confused  by  the  information. 

Finally,  the  question  of  applicability  should  be  resolved.  The  interface  could  be  required  of  each 
clock  brought  aboard  by  each  platform  system.  (A  clock  for  these  purposes  would  contain  its  own 
oscillator  and  therefore  be  able  to  operate  autonomously  for  some  period  of  time).  The  whole 
picture  changes  if  those  responsible  for  platform  design  and  integration  also  take  responsibility  for 
providing  the  precise  time  and  frequency  services  needed  by  all  precisely  timed  systems.  (Such  a 
philosophy  was  adopted  from  the  start  in  the  SSN-688  class  of  submarines  and  likely  some  other 
platforms).  This  approach  is  the  one  with  the  greatest  potential  for  success. 
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Figure  2  One  Pulse  per  Second  Output 


Example  of  Standard  1PPS  Input  Circuit 
Figure  3. 
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QUESTIONS  AND  ANSWERS 

G.  Winkler,  USNO:  I  think  your  excellent  paper  has  raised  several  points.  First  the  identification 
of  the  second  and  the  problem  of  identification  of  the  year.  Many  systems  and  our  own 
operations  with  the  observatory  identify  the  second  through  the  MJD  plus  six  decimals.  That 
is  a  very  convenient  way,  strictly  decimal  and  very  easy  to  convert  into  any  other  format.  After 
all,  the  calendar  is  well  defined  in  advance  and  I  think  it  avoids  all  these  problems  of  the  year 
change  and  the  century  and  what  have  you.  Second  point,  in  the  DSCS  there  is  no  reason 
what  so  ever  why  the  DSCS  came  up  without  the  same  standards  with  the  same  procedures 
as  LORAN  and  GPS  and  that  is  simply  to  ignore  the  leap  second  within  the  system.  The 
problem  is  that  we  have  difficulty  in  getting  everybody  together  because  DSCS  is  operated 
through  the  services  with  a  more  or  less  loose  supervision  by  (  ?  )  and  the  problem  is 
purely  one  of  coordination,  but  my  recommendation  would  be  to  do  exactly  the  same  thing 
as  what  we  do  in  LORAN.  That  is  have  no  interruption  what  so  ever  and  a  coherence  in 
the  electrical  system,  but  do  things  through  a  table  of  coherence  or  a  table  of  offset.  After 
all  OMEGA,  LORAN,  GPS  and  all  of  these  systems  do  that  and  they  avoid  the  problems  of 
resetting  modems  and  things  like  that.  That  would  be  my  recommendation.  The  last  point  I 
wanted  to  make  is  to  talk  and  clarify  the  situation  with  the  UPC  reference.  That  has  come 
home  very  convincingly  during  the  last  meeting  which  in  fact  Dr.  Beard  has  organized  with 
the  NATO  representatives.  That  is  really  the  only  one  way  to  do  that  and  that  is  for  GPS 
through  the  observatory  reference.  To  produce  as  close  a  predicted  value  of  UTC  BIPM  as 
we  can  make,  because  there  is  no  better  way  to  do  it.  The  BIPM  values;  they  come  one  or 
two  months  in  arrears  and  we  have  to  have  a  real  time  reference.  The  only  way  to  avoid 
endless  disputes  and  confusion  is  to  adopt  that  policy  and  we  have  adopted  that  policy.  There 
is  only  one  difficulty  and  that  is  the  annual  terms,  which  exist  in  practically  every  operation 
when  it  goes  to  that  kind  of  a  precision  to  nanoseconds  instead  of  long  term  time  keeping. 
But  I  believe  that  problem  will  go  away  with  the  installation  of  a  great  number  of  the  new 
cesium  clocks  into  the  system,  the  international  system.  They  are  much  less  sensitive  to  time, 
to  temperature  fluctuations  and  that  will  eliminate,  I  hope  a  great  deal  of  that  annual  term. 
Until  that  happens  the  price  that  you  pay  are  more  frequent  small  frequency  changes  in  the 
observatory  time  scale.  These  frequency  changes  are  in  the  order  of  one  or  two  parts  in  ten 
to  the  fourteen  and  they  come  practically  every  month.  Whenever  a  new  bulletin  from  the 
BIPM  arrives  we  have  to  change  our  prediction.  This,  I  think  will  go  away  as  time  goes  on 
and  we  have  a  much  better  international  system.  Some  discussion  about  what  can  be  done, 
in  that  regard,  by  including  better  methods  to  make  international  time  comparisons  including 
some  recommendations  by  the  GPS  Standardization  Group,  as  we  had  yesterday.  Considering 
a  slight  change  maybe  in  the  way  (?)  is  implemented  by  BIPM.  All  of  that  will  be  discussed 
in  a  meeting  next  March.  We  will  be  very  much  interested  to  get  some  additional  inputs 
concerning  this  questions. 

J.  Levine,  NIST:  I  would  like  to  endorse  Dr.  Winkler’s  recommendations  very  strongly;  in 
particular  two  of  his  recommendations.  (1).  That  time  be  given  in  terms  of  Modified  Julian 
Day  number  in  seconds  which  we  use  as  well;  it  is  a  very  useful  system.  I  think  that’s  an 
extremely  good  idea.  (2)  Endorse  very  strongly  is  the  idea  of  using  UTC  BIPM.  There  is  a 
difficulty  of  course  as  you  pointed  out  with  predicting  it.  We  have  the  same  difficulties  and 
we  have  steering  of  a  few  parts  in  ten  to  the  fourteenth  every  month  as  well.  I  think  in  the 
long  run  using  UTC  BIPM  allows  international  coordination  that  allows  for  hand  over  among 
different  standards  laboratories.  I  think,  I  agree  with  you  there  are  problems  now  and  this  is 
a  goal  we  ought  to  move  towards;  because  it  will  facilitate  international  coordination. 

G.  Winkler:  The  reaction  to  the  first  thing,  and  that,  is  for  an  electronic  system  such  as  the 
DSCS  to  avoid  the  leap  second  by  simply  continuing  coherently  and  leave  that  change  to  the 
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interface  between  your  electronic  system  and  the  clock  on  the  wall.  We  do  this  with  the  table 
of  coincidences  as  in  the  case  of  LORAN  and  through  the  GPS  minus  UTC  correction  which 
is  another  navigation  message  of  GPS. 

Comment  I  am  not  clear  when  you  say  GPS  has  no  leap  second.  I  did  an  experiment  in 
which  the  satellite  message  has  knowledge  .. 

J.  White,  NRL:  They  broadcast  the  correction;  there  are  multiple  time  scales  broadcast  by 
GPS. 

G.  Winkler:  What  we  mean  is  the  system,  the  electronics  go  on  uninterrupted.  There  is  no 
step,  no  resetting.  Eveiything  is  done  through  the  information  change.  What  you  do  is  you 
change  the  information  in  the  navigation  message,  you  change  from  7  seconds  to  8  during  the 
next  leap  second.  That  is  much  easier  to  accomplish  than  to  reset  the  whole  system;  reset 
clocks.  In  a  case  of  the  DSCS,  what  is  being  done  and  what  has  to  be  done  right  now  is  at 
some  convenient  time  when  the  system,  in  other  words,  the  star  or  whatever  communication 
arrangement  you  have,  when  they  have  the  calibration  period  then  they  can  reset  their  modems 
to  the  new  time  10  second  period.  I  think  this  is  a  great  inconvenience  and  should  be  avoided. 

Question:  What  GPS  documents  also  have  the  algorithms  that  tell  you  how  GPS  receivers 
should  handle  and  ... 

J.  White:  Yes,  absolutely  that  is  all  in  there.  The  GPS  time  itself  does  not  have  the  leap 
seconds  in  it,  they  broadcast  the  leap  second  corrections  to  generate  UTC. 

Question:  What  is  your  recommendation  on  Figure  of  Merit? 

J.  White:  I  do  not  have  a  recommendation  on  Figure  of  Merit.  I  point  out  that  Figure  of 
Merit  is  something  a  lot  of  people  want,  that  I  do  not  think  is  handled  well  at  the  moment. 

Comment:  At  the  last  ICD060,  our  agency  was  helpful  in  writing  it  up,  and  want  everyone  to 
know,  if  they  have  any  recommendation  on  that  ICD,  there  is  a  (  ?  )  process,  a  working  group 
meeting  and  that  has  not  occurred  for  that  ICD  for  awhile.  If  you  have  recommendations  for 
GPS  changes,  they  should  be  submitted  through  JAPO  and  put  in  for  future  ICD  meetings  to 
determine  whether  or  not  these  changes  will  be  considered  or  approved;  and  that  is  rare. 

G.  Petit,  BIPM:  If  the  leap  second  is  really  a  problem,  why  not  think  of  removing  this  leap 
second,  at  least  until  we  can  introduce  leap  powers  for  example.  Anyone  who  wants  to  know 
precisely  the  rotation  of  the  earth,  why  not  stop  thinking  of  removing  the  leap  second. 

G.  Winkler,  USNO:  I  agree  with  you,  in  fact,  when  the  leap  second  thing  was  brought  up  in 
1967,  the  first  proposal  was  to  do  it  every  leap  day.  However  many  seconds  will  be  required  at 
that  moment,  usually  three  or  fbur,  but  that  would  require  the  tolerance  limit  to  be  extended 
from  nine  tenths  or  one  second  to  more  than  ten  seconds.  There  was  a  tremendous  resistance 
to  that  and  I  do  not  know  if  that  would  be  possible  today.  That  is  a  subject  that  CCDS  should 
address  in  the  next  March  meeting. 

J.  Cecil,  NUWC:  I  am  the  current  chairman  of  the  Range  Commander  Council  Telecommu¬ 
nications  Group  Timing  Committee.  We  are  the  ones  that  established  these  IRIG  standards. 
I  do  not  have  a  question,  but  I  would  just  like  to  make  the  comment  that  when  we  go  out 
and  interrogate  other  DoD  ranges  to  ask  them,  or  inquire  about  upgrading  these  standards, 
we  have  a  great  deal  of  difficulty  getting  responses  in  a  lot  of  cases.  We  would  like  to  see  that 
changed,  so  I  can  see  your  point  in  a  lot  of  comments  on  what  you  would  had  to  say. 


134 


Ron  Beard,  NRL:  One  comment  on  the  leap  second  consideration  in  the  NATO  arena,  which 
I  am  the  U.S.  representative  on  a  working  group.  They  are  considering  recommending  adding 
a  field  for  dissemination  of  leap  second  information  through  the  standardized  interface.  So 
that  is  one  approach  around  that.  I  think  the  significant  point  that  has  not  been  raised  this 
morning  through  Joe’s  rather  good  paper  is  where  is  the  interface?  Is  it  between  a  clock  and  a 
local  reference  system?  Is  it  in  the  field  between  system  units?  Exactly  where  is  the  interface 
that  can  be  standardized.  This  is  a  problem  we  run  into  in  the  NATO  arena.  It  is  something 
that  needs  to  be  considered. 
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